home *** CD-ROM | disk | FTP | other *** search
/ Shareware Grab Bag / Shareware Grab Bag.iso / 087 / tcommsys.arc / BULLET1 < prev    next >
Encoding:
Text File  |  1987-08-01  |  8.7 KB  |  185 lines
  1.  
  2. XMODEM File Transfer Protocol
  3.  
  4.  
  5. By Larry Jordan
  6.  
  7.  
  8. When transferring files between computers using the telephone
  9. system, there is always the chance that electrical noise will
  10. result in data transmission errors. To ensure proper transfer of
  11. files it is necessary to detect data transmission errors and to
  12. retransmit data that contains errors. Most people think that
  13. asynchronous parity error detection provides that capability. It
  14. does not. Parity error detection does tell you when a data
  15. transfer error has occurred, but it is up to you to retransmit
  16. the data to correct errors. The problem is that parity error
  17. detection is not actually performed by most IBM PC communication
  18. packages. If a package does perform the error detection, it may
  19. not inform you of errors in such a way that you know to
  20. immediately retransmit the data. ASCOM, for example, places an
  21. asterisk in a file where parity errors are detected, but you
  22. may not realize the errors occurred until long after the file is
  23. transferred. To ensure "error-free" data transfer you need a
  24. protocol file transfer technique.
  25.  
  26. A protocol is a set of rules and conventions that apply to a
  27. specific area of communications that allow participants to
  28. properly communicate regardless of the hardware brand or software
  29. package being used. The protocol file transfer is a set of rules
  30. for transferring files which specifies a set of ASCII handshaking
  31. characters and the sequence of handshaking required to perform
  32. certain file transfer functions. Protocol handshaking signals
  33. allow communication software to transfer text, data and machine
  34. code files, and to perform sophisticated error-checking. The
  35. handicap in using protocol file transfer techniques is that the
  36. computers on both ends of the communications link must be using
  37. compatible software; there is no standard that controls these
  38. protocols.
  39.  
  40. The Ward Christensen XMODEM protocol is one specific file
  41. transfer protocol that has become a default standard in personal
  42. computer communications because of its widespread use on bulletin
  43. boards and because of its inclusion in low cost personal computer
  44. communication packages such as PC-TALK.  Widespread acceptance of
  45. XMODEM in business communication packages has been slow, partly
  46. because the protocol is public domain; many business
  47. communication package designers use unique protocols to force
  48. businesses to use their software on both ends of communication
  49. links.
  50.  
  51. By providing you with this insight into protocol transfer
  52. and explaining in detail the operation of the XMODEM protocol, I
  53. hope to add momentum to the development of a "standard protocol"
  54. whether it be the XMODEM model or some other model. Users of
  55. communication software deserve a standard protocol that will
  56. allow them to use the technique with any microcomputer regardles
  57. of the software packages employed. Protocol file transfers with
  58. mini and mainframe computers are also desirable and are
  59. addressed in the KERMIT article in this issue of the Monitor.
  60.  
  61. The XMODEM protocol is illustrated in Figure 1.  As you can see
  62. from that figure, XMODEM does not begin the transfer of data
  63. until the receiving computer signals the transmitting computer
  64. that it is ready to receive data.  The Negative Acknowledge (NAK
  65. -- ASCII 21) character is used for this signal and is sent to the
  66. transmitting computer every 10 seconds until the file transfer
  67. begins.  If the file transfer does not begin after 10 NAK's are
  68. sent, the process has to be manually restarted.
  69.  
  70. After a NAK is received, the transmitting computer uses a Start
  71. of Header (SOH -- ASCII 01) character to signal the start of a
  72. data block transfer.  The SOH is followed by two numbers.  The
  73. first number is the number of the data block to be transmitted,
  74. and the second number is the ones complement of the data block
  75. number.  The ones complement is the block number XOR 255 or
  76. simply 255 minus the block number.
  77.  
  78. The block number and the ones compliment number are then followed
  79. by a 128-byte block of data and an error-checking checksum.  The
  80. checksum is calculated by adding the ASCII values of each
  81. character in the 128 character block; the sum is then divided by
  82. 255 and the remainder is retained as the checksum.  After each
  83. block of data is transferred, the receiving computer computes its
  84. own checksum and compares the result to the checksum received
  85. from the transmitting computer.  If the two values are the same,
  86. the receiving computer sends an Acknowledge (ACK -- ASCII 06)
  87. character to tell the receiver to send the next sequential block.
  88. If the two values are not the same, the receiving computer sends
  89. the transmitter an NAK to request a retransmission of the last
  90. block This retransmission process is repeated until the block of
  91. data is properly received or until 10 attempts have been made to
  92. transmit the block.  If the communications link is noisy,
  93. resulting in improper block transmission after 10 attempts, the
  94. file transfer is aborted.
  95.  
  96. XMODEM uses the block number and the ones compliment block number
  97. at the start of each block to be sure the same block is not
  98. transmitted twice because of a handshake character loss during
  99. the transfer.  The receiving computer checks the transmitted
  100. block to be sure that it is the one requested and blocks that are
  101. retransmitted by mistake are thrown away.  When all data has been
  102. successfully transmitted, the transmitting computer sends the
  103. receiver an End of Transmission (EOT -- ASCII 04) character to
  104. indicate the end of file.
  105.  
  106. The XMODEM protocol offers the IBM PC several advantages over other
  107. protocols and file transfer methods. First, the protocol is in
  108. the public domain which makes it readily available for software
  109. designers to incorporate into a communications package. Second,
  110. the protocol is easy to implement using high level languages such
  111. as BASIC or Pascal. Third, the protocol only requires a 256-byte
  112. communication receive buffer which makes it attractive for IBM PC
  113. owners who only have 64K systems. Forth, the protocol allows a
  114. user to transfer non-ASCII 8-bit data files (i.e., COM, EXE and
  115. tokenized BASIC) between microcomputers because it calculates the
  116. end of a file based on file size and uses handshake signals to
  117. indicate the end of a file instead relying on an end of file
  118. marker character (control-Z) to terminate a file transfer.
  119. Fifth, XMODEM error-checking is superior to normal asynchronous
  120. parity error checking.    The parity method of error-checking is
  121. 95% effective if the software on the receiving end checks for
  122. parity errors.    XMODEM error-checking is 99.6% effective, and the
  123. software on the receiving end must check for errors.  Parity
  124. errors detected also do not result in automatic retransmission of
  125. the bad data; XMODEM detected errors result in data
  126. retransmission until no errors are detected or until 10
  127. retransmissions have been attempted.  Finally, the protocol is
  128. used by many bulletin boards and having the protocol in a
  129. communications package allows the IBM PC user to receive
  130. error-checked files from these bulletin boards.
  131.  
  132. XMODEM does not solve all communications problems, but it does
  133. provide compatable file transfers between a large variety of
  134. computers. The inclusion of this protocol in PC-TALK.III and many
  135. commercial packages has provided a common denominator that we
  136. needed in data communications. Now that we have this common
  137. microcomputer link, it is time to apply pressure for a more
  138. universal public domain asynchronous communications protocol that
  139. can be used between any two computers.
  140.  
  141.  
  142.          XMODEM Protocol File Transfer
  143.  
  144.  
  145. Receiving                       Transmitting
  146. Computer                     Computer
  147. Ready to                     Ready to
  148. Receive                      Transmit
  149.    |                            |
  150.    |                            |
  151.    |---------------------\NAK\--------------------->|
  152.    |                            |
  153.    |<---------/SOH/001/254/Good Data/CkSum/---------|
  154.    |                            |
  155.    |---------------------\ACK\--------------------->|
  156.    |                            |
  157.    |<---------/SOH/002/253/Good Data/CkSum/---------|
  158.    |                            |
  159.    |---------------------\ACK\--------------------->|
  160.    |                            |
  161.    |<---------/SOH/003/252/Garbled Data/CkSum/------|
  162.    |                            |
  163.    |---------------------\NAK\--------------------->|
  164.    |                            |
  165.    |<---------/SOH/003/252/Good Data/CkSum/---------|
  166.    |                            |
  167.    |---------------------\ACK\--------------------->|
  168.    |                            |
  169.    |<--------------------/EOT/----------------------|
  170.    |                            |
  171.    |---------------------\ACK\--------------------->|
  172.    |                            |
  173.    V                            V
  174.  
  175.   File                           File
  176. Receipt                      Transmit
  177.   Ends                           Ends
  178.  
  179.                Figure 1
  180.  
  181. -------------------------------------------------------------------
  182. Larry Jordan coauthored the book
  183. COMMUNICATIONS and NETWORKING for the IBM PC,
  184. published by the Robert J. Brady Company.
  185.